Copyright ⌐ 1995, Macneil Shonle. All rights reserved.
Contents
Introduction
Use of BufferAccessor
About the Sprite class
What is to come
Frequently Asked Questions
Notes on Style
In Closing
Introduction
The following component explained here is the evolution of some direct blitting classes I had made for my own personal use. As I used the classes more and more I was able to see what was needed in the classes, and what wasn╒t. The result was a much simpler and cleaner design that can be useful to anyone interested in speeding up their graphics routines.
If you want to directly access a GWorld, all you have to do is supply a pointer to it in the constructor for a GWorldAccessor object. Take a look at the following code, it will directly access the GWorld╒s pixel-map to draw a black dot at coordinate (12, 16), that is, assuming that myGWorld is pointing to a GWorld created with NewGWorld:
GWorldAccessor gworldBuff(myGWorld);
gworldBuff.setPixel(12, 16, 0xFF);
Previously, the same class that provided access to the pixel-map also created it. This looked simpler on the outside, but was too limiting to users of other frameworks and put too much complexity into one class. For users who liked the encapsulation of the GWorld (so they didn╒t have to worry about calling NewGWorld and DisposeGWorld), I have provided a set of SecureMacPorts to be used:
Rect bounds = {0, 0, 400, 400};
SecureGWorld gworld(bounds);
GWorldAccessor gworldBuff(gworld);
// ...
Use of BufferAccessor
The power of polymorphism can be shown by having a series of blitting functions use a BufferAccessor& as their parameter. For example, look at this (inefficient) function that fills the parameter╒s pixel-map to black:
void Flood(BufferAccessor& buff)
{
for (PixelCord y=0; y<buff.getHeight(); y++)
for (PixelCord x=0; x<buff.getWidth(); x++)
buff.setPixel(x, y, 0xFF);
}
Note that this may be a window or a GWorld, the code doesn╒t care and works either way. Now take a look at a more efficient version:
This can be optimized even more, but the use and simplicity of the accessors should be clear now. You may have noticed the use of the MMUModeSwapper class (from <MMUModeSwapper.h>). It uses the ╥resource acquisition is initialization╙ technique (see 9.4 of Stroustrup). When the object is initialized, the constructor puts the machine into the correct addressing mode. It is up to the destructor to return the machine back to the previous state. Similar to the MMUModeSwapper, there is a GWorldSetter. This technique is useful because (1) it reduces the amount of code to be writen, in a clear and elegant manner; (2) it ensures that the state will always be returned, important for when an exception is thrown; and (3) a programmer might forget to return the state back otherwise.
The header <PixelTypes.h> is useful if ever the bytes-per-integral-type change in an implementation; that way, all of the code that will have to be rewriten would be in one place (the header).
About the Sprite class
This release comes with a CIconSprite class, which has not been heavily tested but appears to work for my purposes. Not all of the member-functions for it are implemented, such as member-functions providing persistence. The sample program MySprite uses them, and another class called ForeGroundObject.
(The sample program isn╒t even event driven. Click the mouse to quit it, or wait until profiling is done. Always use the profiler. Metrowerk╒s has the best Macintosh profiler I╒ve seen.)
Please tell me what you would like to see in the sprite classes, as they are incomplete. Note that the sprite abstraction is only for drawing the images and handling the bitmaps, nothing else. More complex code that handles posistions and animation frames belong in something like ForeGroundObject, not in the raw drawing classes for them.
What is to come
In the ╥Blitting Class Library╙ folder, there is a folder named ╥Plans,╙ which includes a sample of what the ImageCopier class will look like. This should be useful for programs that can change their mind at run time about which copy method to use (CopyBits vs. direct). In an imformal test I did on the PowerPC, the CopyBits routine took 80% of all processor time (mind you it was calling CopyBits a lot). I replaced all calls to CopyBits with a blitter of my own, and total processor time dropped to 60%.
Collision detection will be added into the sprite classes. A class for fading the screen is also planned, and I╒ll probably throw in some functions for hiding the menu bar, just for sport.
Frequently Asked Questions
Ñ What is Blitting?
The word ╥blit╙ came from the PDP-11 instruction BLT (BLock Transfer). This instruction was used to move graphics from one place to the other, back in the old days. Now blit has a more general meaning and implies graphics operations. For example, something that draws sprites on the screen would be a sprite blitter.
Ñ What is a Sprite?
A sprite is any moving object on the screen that has a mask.
Ñ Why can╒t the code compile? Something is wrong with the headers, I think.
Move the ╥Blitting Class Library╙ folder to the system level (i.e. the folder with the compiler in it). That╒s because I use #include <name.h> instead of #include "name.h". That╒s all.
Notes on Style
The style of the code has changed completly since the CDirectBlit release of these classes (you can call this the BufferAccessor release). Support for exceptions have been brought in, and everything is much more atomic (the two changes went hand-in-hand). It was much harder to design this version than past versions, but it was much simpler to implement.
On a less important note: The naming coventions have been changed, and no longer use PowerPlant-like prefixes. The name CDirectBlit was a misnomer if I ever saw one, and was briefly changed to DirectBuffer before the design changed to the current accessor version. I also changed the member-function naming convention so that the first letter of each function is in lower case, which matches the good style I╒ve seen in the books: Advanced C++ Programming Styles and Idioms and C++ FAQs, and in Smalltalk. Another note: mangling the data member names seems kind of silly, if you ask me. The brace placement has been changed to the more traditional K&R style. I still use the ╥#ifndef/#define/#endif╙ technique to avoid the inclusion of a header file twice, which is less implementation dependant than ╥#pragma once╙ is.
In Closing
These classes have been made to aid blitting code for those who do not want to change their project to a whole new library when all they want to do is just get the base address of a GWorld. These are the people I had in mind while writing this code. If you have a GWorld already made with PowerPlant, you can still benefit with direct access, and with my classes.
Finally: I need more input from people who have downloaded these classes. Do you like them? Do you hate them? Is there something you wished they had or did or didn╒t do? Any input will help me. Send all comments via email to: macneils@aol.com.
Feel free to upload this code anywhere, but only the original archive. You may change the code for your own uses (such as making functions inline), but you are not given permission to distribute it in the changed form. Use the Blitting Class Library, or parts of it, at your own risk. If the libarary is used in a project, you are not obligated to give credit╔ but it would be nice if you were to. The code is free (donations accepted), enjoy!
